Mobile Phones and Wearables:
Purpose–Capability Designs
A P-AXIM exploration of journey-aware, content-aware and
context-aware personal devices
Discussion
note | October 2026
From a phone that communicates to a personal system that senses,
understands, prepares and coordinates.
Srijan Sanchar proposes exploring mobile
phones and wearables as coordinated personal interfaces to a wider journey- and
content-aware network. Rather than treating a phone only as a screen, radio and
application platform, the design space is expanded across five
purposes—Connect, Know, Transact, Decide and Act—and five capabilities—Connect,
Sense, Understand, Create/Simulate and Act/Coordinate.
The Purpose–Capability Matrix is a
product-discovery instrument. Probable combinations generate designs that can
be assembled from existing or near-term technologies; improbable combinations
deliberately cross conventional boundaries to identify research hypotheses.
P-AXIM combines capabilities across the phone, wearables, transport
information, content schedules and network services.
Core proposition: devices should help
people prepare for what is likely to happen, not merely react to what is
happening now. For journeys, this means maintaining a probabilistic picture of
route, timing, transfers and likely connectivity conditions. For content, it
means preparing useful information and helping networks anticipate demand
peaks.
·
Purpose before feature: start
with a human task, not a sensor looking for a use.
·
Combine capabilities: pair
sensing with understanding, understanding with simulation, and simulation with
authorised action.
·
Journey continuity: treat a
journey as connected stages rather than disconnected map instructions or cell
handovers.
·
Content-aware preparation: use
schedules and privacy-protective aggregate forecasts to prepare for predictable
demand peaks.
·
Phone–wearable complementarity:
the phone is the main interaction, compute and connectivity hub; wearables
provide low-friction sensing, feedback and specialised form factors.
·
Uncertainty-aware behaviour:
maintain alternative trajectories and confidence levels; never present
forecasts as certainties.
·
Privacy by design: prefer
on-device processing and aggregate data; individual journey or health-related
signals need appropriate user control.
·
Interoperability: complement
established cellular, Wi-Fi, Bluetooth, positioning and application mechanisms
rather than assume they are replaced.
Rows describe the human purpose; columns
describe the capability used to serve it. The cells are prompts for design, not
a claim that every combination should become a separate product.
|
Purpose ↓ / Capability → |
Connect |
Sense |
Understand |
Create / Simulate |
Act / Coordinate |
|
CONNECT |
Calls, messaging
and session continuity |
Detect link,
movement or environment changes |
Select
communication mode for context |
Simulate
alternative links or service paths |
Coordinate
phone, wearable, Wi-Fi, cellular and approved relays |
|
KNOW |
Receive trusted information |
Sense location, motion, surroundings or device
state |
Interpret context, content and likely needs |
Explore scenarios and explain outcomes |
Deliver alerts or share permitted status |
|
TRANSACT |
Payments,
tickets and identity checks |
Detect proximity
or transaction context |
Validate intent
and reduce friction |
Preview cost,
timing or failure scenarios |
Coordinate
ticket, payment, credential and confirmation |
|
DECIDE |
Advice and decision support |
Gather journey, connectivity and context signals |
Rank options against user goals |
Compare routes, schedules and possible futures |
Carry out user-approved changes |
|
ACT |
Communicate a
chosen action |
Detect triggers
and changing conditions |
Choose responses
within constraints |
Test an action
before commitment |
Coordinate
devices, apps and authorised services |
These designs prioritise practical
combinations likely to be prototyped with existing components and services.
Sanskrit-derived names are working names and should be linguistically checked
before branding.
Matrix:
Know × Understand; Decide × Create/Simulate; Connect × Act/Coordinate.
Maintains a Probabilistic Journey Register
(PJR): planned route, alternatives, expected arrival windows, transfer points,
confidence and update triggers. Combines navigation information with a
separately estimated connectivity forecast where available.
User value: flags transfer risk, suggests
alternatives, and preloads essential maps or tickets. First test: route/ETA
feeds, local journey storage and user-selected objectives. A mapping route
alone does not predict exact radio handovers.
Matrix:
Connect × Understand; Connect × Act/Coordinate.
A policy-driven connection manager chooses
among available cellular, Wi-Fi and approved companion links using service
need, security, cost, battery and measured quality.
User value: prioritises continuity for
calls, navigation and ticketing while avoiding unnecessary scans or switching.
First test as an application-level policy layer; radio-level control remains
with the operating system, modem and network standards.
Matrix:
Know × Sense; Know × Understand; Decide × Create/Simulate.
Uses user-selected calendars, public event
schedules and local context to prepare relevant information before predictable
demand or connectivity constraints.
User value: preloads tickets, maps,
translations and essential documents; suggests downloading large files before a
known peak. Begin with explicit user-selected events; network-wide forecasts
require aggregate feeds and operator participation.
Matrix:
Transact × Understand; Transact × Act/Coordinate.
Combines journey context with secure
ticketing, payments, access credentials and confirmations in one
user-controlled flow.
User value: reduces repeated entry and
preserves transaction state when connectivity drops. Prototype with sandbox
APIs and clear confirmation states; location alone must never authorise
payment.
Matrix:
Act × Understand; Act × Create/Simulate; Act × Act/Coordinate.
Sequences approved actions across
navigation, calendar, messaging, ticketing and accessibility settings.
User value: after a train delay, it can
compare revised routes, draft a message and ask before changing a booking.
Start with recommendations and confirmation, permissions and audit logs.
Matrix:
Know × Sense; Decide × Understand.
A low-power wearable senses movement and
user-selected activity states, sharing only necessary cues with the phone.
Haptic cues for transfers, platform changes
or missed turns can reduce the need to look at a screen. Test with motion
sensing and phone-derived route context; do not claim the band alone knows
exact location.
Matrix:
Know × Understand; Connect × Act/Coordinate.
A glanceable interface for navigation
arrows, translated signs, short alerts and ticket prompts, with the phone doing
most compute and connectivity work.
Hands-free information during transfers.
Start with opt-in prompts; any camera-based scene understanding needs visible
controls and privacy safeguards.
Matrix:
Connect × Understand; Know × Act/Coordinate.
An ear-worn interface for spoken
navigation, multilingual announcements, content summaries and fallback
messages.
Keeps instructions available while the
screen is pocketed and can use cached directions when live service degrades.
Preserve ambient awareness and safety announcements.
Matrix:
Know × Sense; Act × Act/Coordinate.
A wristband, clip or garment interface
translates navigation and service states into tactile patterns.
Useful in noisy settings, hands-busy travel
and some accessibility contexts. Test whether patterns remain distinguishable
while walking; offer intensity controls and an easy off switch.
Matrix:
Connect × Act/Coordinate; Decide × Understand.
A companion wearable linked to the phone
for user-requested check-ins, journey milestones, emergency-contact workflows
and battery/connectivity warnings.
Helps prepare a fallback when battery or
connectivity deteriorates. Keep check-ins transparent and user-configured; no
covert tracking or default continuous sharing.
These concepts deliberately stretch the
conventional phone–wearable boundary. They are research hypotheses, not claims
of technical readiness or established novelty.
Phone, watch, earbuds, glasses and nearby
authorised devices cooperate as sensing, display and connectivity endpoints.
The system chooses where a task should run and where information should appear.
Value
and research challenge: Potential value: resilience
and lower interaction friction. Barriers: synchronisation, interoperability,
privacy boundaries and energy overhead.
A garment, strap or device shell changes
physical properties or configuration for visibility, tactile structure, thermal
behaviour or antenna geometry using safe reconfigurable materials.
Value
and research challenge: Potential value: one
wearable adapting to multiple tasks. Barriers: durability, power, comfort,
washability, RF performance and certification.
Instead of one route and ETA, the interface
presents a confidence-aware field of possible arrivals, transfer risks and
connectivity conditions, showing what evidence might change the recommendation.
Value
and research challenge: Potential value: better
decisions under uncertainty. Barriers: cognitive overload, calibration and
avoiding false precision.
With opt-in participation and aggregate
processing, devices contribute protected signals about crowd movement, route
disruption and local service quality without a central record of every person's
journey.
Value
and research challenge: Potential value: earlier
detection of bottlenecks. Barriers: privacy, sparse participation,
manipulation, bias and re-identification risk.
A phone–wearable system stages information,
computation, interface elements and connectivity options before a task arises,
keeping alternatives ready and committing only after a trigger or confirmation.
Value
and research challenge: Potential value: fewer
delays during transfers, peaks or weak-coverage segments. Barriers: wasted
prefetching, stale data, battery cost and mistaken anticipation.
|
Layer |
Function |
Design rule |
|
1. Journey
intelligence |
Routes,
timetables, event schedules, user-declared intent, transfers and disruption
feeds. |
Phone-local
where possible; user controls. |
|
2. Probabilistic Journey Register |
Likely path and alternatives, time windows, confidence,
connectivity constraints and update triggers. |
Share only the fields required for a specific
service. |
|
3. Proximity and
group reasoning |
Estimate
aggregate arrival waves and shared demand without assuming every traveller
has identical intent. |
Prefer
aggregate, privacy-preserving computation. |
|
4. Predictive connectivity |
Combine journey context with measured or
operator-supplied coverage, quality, capacity and service forecasts. |
Separate route/ETA prediction from radio
prediction; state confidence. |
|
5. Device Core
and Shell |
Core maintains
state and policies; Shell presents information through phone, watch, glasses,
audio and haptics. |
Interoperable
APIs and consistent accessible controls. |
|
6. Authorised action |
Preload information, suggest alternatives,
coordinate approved device functions or request network service changes. |
User confirmation and operator authority for
consequential actions. |
|
7. Outcome
learning |
Compare expected
and actual travel time, transfer success, connectivity, energy and feedback. |
Measure
incremental benefit; allow correction and deletion. |
|
Context |
Phone / wearable response |
Measures |
|
Live sport or
major release |
Prepare relevant
content, schedule non-urgent downloads, show service expectations and use
aggregate event forecasts for operator capacity planning. |
Buffering,
throughput, forecast error, energy and user experience. |
|
Rail or metro journey |
Preload tickets/maps, estimate transfer risk, offer
alternative routes, provide haptic/audio cues and prepare for known coverage
gaps. |
Transfer success, journey time, missed turns,
session continuity and battery. |
|
Exam results or
public announcement |
Prepare cached
official links, accessible summaries and status messaging; aggregate demand
forecasts can support capacity preparation. |
Successful
access, latency, failure rate, equity and false forecasts. |
|
Disruption or unexpected crowd |
Combine official alerts and permitted aggregate
signals; recommend alternatives while preserving transport authority and
safety rules. |
Detection time, false alerts, recovery time and
passenger-flow impact. |
|
Low-connectivity
area |
Store essential
information locally, prioritise low-bandwidth service and explain offline
states clearly. |
Offline task
completion, energy, reliability and affordability. |
|
Phase |
Candidate designs |
Approach |
Gate to proceed |
|
Phase 1:
Software prototypes |
YĀTRĀ, BODHI,
SPANDA, ŚRAVAṆA |
Use existing
phones and wearables; no hardware redesign required. |
Validate
usefulness, forecast confidence and accessibility. |
|
Phase 2: Cross-device orchestration |
SŪTRA, SAHAJ, ANVAYA, SPARŚA |
Connect app services and wearable feedback under
user-approved policies. |
Validate continuity, transaction recovery,
usability and safe control. |
|
Phase 3:
Operator collaboration |
PJR plus
aggregate journey/content intelligence |
Pilot with
transport, telecom and content partners using limited data. |
Prove
incremental value over existing forecasts. |
|
Phase 4: Research demonstrators |
MOSAIC, CHAMELEON, ORBIT, CHORUS, LIMEN |
Test distributed endpoints, programmable materials,
uncertainty interfaces and privacy-preserving collective intelligence. |
Demonstrate measurable advantage and quantify cost,
risk and maturity. |
·
Purpose fit: does the design
solve a real user task better than the current workflow?
·
Incremental prediction value:
does journey or content context improve the baseline forecast enough to change
an action?
·
Service outcomes: measure
journey time, transfer success, availability, throughput, latency, task
completion or transaction recovery as relevant.
·
Resource cost: measure battery,
data, compute, integration, operator effort and infrastructure cost.
·
Robustness: test late trains,
route changes, poor location estimates, missing feeds, outages and stale cached
information.
·
Human factors: assess
distraction, trust, accessibility, understanding of uncertainty and ease of
opting out.
·
Privacy and security: minimise
data, process locally where practical, use clear permissions and retention
limits.
·
Novelty and freedom to operate:
search patents, standards and research before making invention or ownership
claims.
The proposed concepts are design
directions, not assertions that Srijan Sanchar owns the underlying
technologies. Connectivity management, caching, broadcast delivery, route
planning, wearables, contextual assistants and predictive network optimisation
are established fields. Potential contribution may lie in specific
combinations, interfaces, decision policies, data-sharing arrangements or
validated use cases; this must be established through prior-art review and
experiments.
Network-facing functions should complement
existing standards and operator control. A consumer application should not
claim to select radio cells, guarantee future coverage or command network
resources unless it has the necessary platform and operator interfaces. Health,
emergency and accessibility features require clear limits and appropriate
validation.
1.
Build a Purpose–Capability
design library for phones and wearables, separating probable product concepts
from improbable research hypotheses.
2.
Create a clickable software
demonstrator of YĀTRĀ + BODHI: a journey register, confidence-aware route
states, preloaded essentials and content-event preparation.
3.
Develop a companion wearable
prototype using haptic/audio prompts for transfer and connectivity
contingencies.
4.
Invite a transport operator,
telecom operator and content or public-information provider to define one
bounded retrospective study.
5.
Publish measured design briefs
showing baseline, incremental benefit, resource cost, privacy model, maturity
and prior-art status.
The Purpose–Capability Matrix suggests a
progression from phones that connect people, to devices that sense and
interpret context, to systems that simulate alternatives and coordinate
authorised actions. Journey-aware and content-aware management is a practical
proving ground because routes and schedules can provide advance warning, while
phones and wearables can translate that warning into timely, user-centred
preparation.
Srijan Sanchar's strongest near-term
proposition is not a speculative new handset. It is a coordinated
phone–wearable experience that prepares the traveller and the network for
likely conditions, preserves user choice and demonstrates measurable improvement
over existing services. More radical material and distributed-device concepts
should remain in a research track until their advantages are demonstrated.